The present invention relates generally to computer systems, and relates more specifically to synchronizing a document with its display screen view or multiple display screen views of the same document after a user has made changes to the document content.
The World Wide Web and the Internet present opportunities to design and display webpages and other Internet viewable documents. Markup languages, such as HyperText Markup Language (HTML) and Extensible Markup Language (XML), are among several programming languages used to design webpages and Internet viewable documents. These languages are different from previously used programming languages, in that markup languages permit the user to describe the structural and formatting content of a text document with the informational content of the same document. When a user writes a webpage or an Internet viewable document, the user inserts markup language xe2x80x9ctagsxe2x80x9d into the informational content of the text document, defining the structure and formatting of the text in the document to be viewed by the user. The computer hardware interprets these xe2x80x9ctagsxe2x80x9d contained in the informational content of the document as formatting and structural instructions for the document. Thus, a user programming in a markup language writes an instructional set of formatting and structural commands directly into the text of the document. When complete, the markup language document is stored in an internal or external memory device for repeated use by the user.
Generally, application programs are pre-programmed sets of instructions that utilize documents and other files stored in memory. A user can make changes to documents and other files using application programs being run on a computer. For example, Microsoft OFFICE is an application program designed to view HTML and XML text documents. When a user views an HTML or XML document using Microsoft OFFICE, the document is displayed by Microsoft OFFICE on a monitor display screen connected to a computer. The user can then input changes to the HTML or XML document through a keyboard or mouse attached to the computer running the application program.
Documents written in HTML and XML can be a composition of several xe2x80x9cchunks,xe2x80x9d with each chunk being a separate HTML or XML document. Interesting subsections of HTML or XML code, otherwise known as xe2x80x9cfactoids,xe2x80x9d may be embedded within the chunks, and may be included in any location within a chunk. Thus, users may create new documents using a combination of chunks and factoids from other documents.
HTML or XML document content may be expressed in a range of different formats and fonts depending upon the markup language used. Even though the user changes the document format or font, the document text content remains the same. A user may also want to change the informational content of the document. The user could add a variety of information to the document including chunks and factoids, text, tables, picture or graphics files, sound files, or any other Internet-usable files.
Whenever the user changes the document format, font expression, or informational content of a document, the user creates a document xe2x80x9cviewxe2x80x9d containing the user change. For example, a user may change the text font of a HTML document from a plain style font to an italicized boldface style font. The user creates a xe2x80x9cviewxe2x80x9d of the original document text content containing the original document content in an italicized boldface style font. Multiple views of the original document text content can be created by the user if additional user changes are made to the original document.
Making changes to a HTML or XML document and applying the changes to a single view or multiple views of the same document can be a difficult and cumbersome process. Multiple views of the same document can be displayed on a single monitor display screen. When the user makes changes to the document, each display screen view of the document must be changed, or the user may be confused by different and inconsistent screen views of the same document content. Typically, the HTML or XML document is stored as a tree-type data structure. For example, when the markup code for a HTML or XML program is stored into a memory device, the HTML or XML code is parsed and stored as a xe2x80x9ctreexe2x80x9d-type data structure for access by the computer hardware.
Furthermore, the management and synchronization of the chunks and factoids within a single HTML or XML document can be a cumbersome process when each chunk and factoid must be stored within a tree-type data structure. Changes made to document chunks cannot be efficiently moved into the display screen view in all instances. The simplest method for updating screen views copies subsections of HTML or XML code stored in the document data tree to all of the screen views. However, this method is slow and cumbersome. In some cases, the application program has difficulties in identifying the changed subsections of the tree-type data structure.
Another method for updating screen views generates fine-grained notifications from a tree/rendering engine concerning the tree-type data structure changes. The notifications are played back to an application program, and the application program listens to the changes and copies the changes to the screen views. However, reading these changes and copying the changes into the screen views is expensive and requires code modifications to the tree/rendering engine. Problems arise with elements not actually in the tree-type data structure for periods of time, such as elements in a move or copy operation.
Yet another method for updating screen views uses a tree/rendering engine to synchronize the views based upon low level changes to the tree-type data structure. However, this method requires major code modifications in the tree/rendering engine resulting in a very fragile code prone to interruptions. Further problems arise with elements not actually in the tree structure for periods of time, such as elements in a move or copy operation.
Thus, representing a document in a tree-type data structure has a number of shortcomings, including (1) the difficulty of consistently determining and describing the precise location of data and the changes made within the tree structure; and (2) the expensive processing time of updating multiple document views by reference to the tree-type data structure when changes are made to the document.
The present invention relates to changing single or multiple views of a HTML/XML document when changes have been made to the document. A tree synchronization module synchronizes the updating of one or more document views when changes are made to the original document.
The present invention provides a consistent and repeatable method for describing the changes made to a document stored in a tree data structure. Documents composed in markup languages including, but not limited to, HTML, XML, and other similar codes may be stored in tree data structures. The changes to tree data structures can be easily recorded and applied to document views. For example, by representing locations within a tree data structure as a consistent and repeatable string of characters, the location of each character in a string is unique and is not based upon any reference to a physical memory structure. References to physical memory structure are used by the prior technology to represent locations in the tree data structure. Identification of these locations is not repeatable when the power is shut off and the locations of the physical memory structure are reset. If a change is made to a document and the change is represented by references to the physical memory structure, then the changes will not be represented in a consistent and repeatable manner if the references to the physical memory structure are changed.
Further, the present invention increases synchronization performance by avoiding excessive processing time used by the prior technology. The prior technology updated the document views by copying subsections of data from the tree data structure of the document to all of the views. Copying the data from the tree data structure to each view is very slow. By utilizing an asynchronous routine, changes recorded in the change logs can be applied to the views during downtime or at any other time processing time is not expensive, without diminishing processing performance.
Generally described, the invention includes a tree synchronization module with two components, a tree synchronization utility program and a tree synchronization engine. The tree synchronization utility program also includes two sub-components, an active data instance and active view instances. The active data instance is configured to receive document changes from a client program or an application program, such as Microsoft OFFICE, and to update the document tree data structures with the received document changes. Once the document tree data has been updated, the active data instance sends the document changes to the tree synchronization engine to generate change logs for each changed view based upon the document changes. The change logs are played to the active view instances configured for updating the view tree data. After the view tree data has been updated, the active view instances sends the view changes to the client program to update the display views.
More specifically, the invention provides a tree synchronization module configured for synchronizing changes to HTML/XML documents with their document views. The tree synchronization module receives changes to a HTML/XML document from an application program, such as Microsoft OFFICE. The active data instance in the tree synchronization utility program receives the document changes using a previously stored set of instructions contained in one or more application program interfaces (APIs). An update processor represents the tree data structure of a document as a flat string of characters, in which every beginning and end point of the tree is represented by a single character. Each character in the string uniquely identifies and describes a point in the tree. When the update processor receives the document changes processed from the stored instructions of the APIs, the update processor can update the document tree data structure with the document changes, and determine the location for the document changes based upon the unique locations of the data within the document character string.
After the document tree data structure has been updated, the document changes are sent to a tree synchronization engine. One or more APIs receive the document changes, and provide a log generator with the document change locations and the data change content. The log generator generates a change log record for each changed document view by recording each document change in terms of the character position within the document character string, and in terms of the content of changes made in the document. Changes in the document can affect multiple document views, thus generating multiple change logs.
Upon the detection of a trigger event by the tree synchronization engine, a log player then plays each change log to the active view instances of the tree synchronization utility program. One or more APIs receive the change logs, and the APIs send the view changes to the active view instances. The active view instances apply the change logs to their respective view tree data to synchronize the document view with the changes made in the document. When the view tree data has been updated, the updated view changes are then sent by the active view instances to the OFFICE application program to update the display views for the user.